In modern computing, many tasks which can be performed on a computer require some level of security. In order to provide a level of security, there are several options. One is to perform all secure applications on a computer which is completely separate from any possibly insecure elements, or to use a virtual machine monitor (VMM) to allow complete separation between two execution environments (e.g. operating systems) running on a single computer system. However, this may be impractical. There may be a need, for cost or convenience reasons, for a secure execution environment to share resources with applications with unassured security, and those applications and those resources may be vulnerable to an attacker. Additionally, where a VMM is used, since a VMM requires full virtualization of the machine and all of its devices (thereby requiring that the VMM provide its own device driver for every possible device), a VMM is not well suited to an open architecture machine in which an almost limitless variety of devices can be added to the machine.
One way to provide the ability to share resources among two execution environments is to provide a computer system in which there is one “main” operating system that controls most processes and devices on a machine, and where a second operating system also exists. This second operating system is a small, limited-purpose operating system alongside the main operating system which performs certain limited tasks. One way to make an operating system “small” or “limited-purpose” is to allow the small operating system to borrow certain infrastructure (e.g., the scheduling facility, the memory manager, the device drivers, etc.) from the “main” operating system. Since a VMM effectively isolates one operating system from another, this sharing of infrastructure is not practical using a VMM.
Certain other techniques allow operating systems to exist side-by-side on the same machine without the use of a VMM. One such technique is to have one operating system act as a “host” for the other operating system. (The operating system that the “host” is hosting is sometimes called a “guest.”) In this case, the host operating system provides the guest with resources such as memory and processor time. Another such technique is the use of an “exokernel.” An exokernel manages certain devices (e.g., the processor and the memory), and also manages certain types of interaction between the operating systems, although an exokernel—unlike a VMM—does not virtualize the entire machine. Even when an exokernel is used, it may be the case that one operating system (e.g., the “main” operating system) provides much of the infrastructure for the other, in which case the main operating system can still be referred to as the “host,” and the smaller operating system as the “guest.” Both the hosting model and the exokernel model allow useful types of interaction between operating systems that support sharing of infrastructure.
Thus, these techniques can be used to provide a computer system with at least two execution environments. One of these may be a “high-assurance” operating system, referred to herein as a “nexus.” A high-assurance operating system is one that provides a certain level of assurance as to its behavior. For example, a nexus might be employed to work with secret information (e.g., cryptographic keys, etc.) that should not be divulged, by providing a curtained memory that is guaranteed not to leak information to the world outside of the nexus, and by permitting only certain certified applications to execute under the nexus and to access the curtained memory.
In a computer system with two execution environments, one of which is a nexus, it may be desirable for the nexus to be the guest operating system, and a second operating system, not subject to the same level of assurance as to behavior, to be the host operating system. This allows the nexus to be as small as possible. A small nexus allows a higher level of confidence in the assurance provided by the nexus. Therefore operating system functions are run by the host operating system.
One such operating system which may be run by the host operating system is a windowing system. When using a windowing system, a user's display will be populated with windows, areas on the screen which display information from an application. An application may have one or more windows.
When the windowing system is run by the host operating system, rather than by the nexus, it is vulnerable to attack. One such possible attack is known as a spoof. A spoof is an attack in which the user is led to believe that some hardware, system software, application or agent software, or a given window, is a trustworthy entity, even though it is not. The attacker is spoofing a trustworthy entity. This can be used to steal user credentials, or to capture other data of a sensitive nature entered by a user who thinks that the user is using a highly assured entity.
For example, in a system in which the nexus runs a banking program with a log-in screen, an attacker may write a program which runs on the host operating system, and displays a window which looks exactly like the log-in screen of the banking program. When the user is fooled by this spoof window, the user will enter information into the spoof window. This information is captured by the attacker and may then be used by the attacker without the knowledge of the user.
The windowing system is also vulnerable to an attack known as a snooker. In a snooker attack, the attacker changes the user display to make it appear to a user that the system is secure, when it is not. For example, a computer system may include the ability for a user to lock the system, or to allow the computer to sleep or hibernate. A snooker attack, in this case, would simulate the screen displayed when the system is locked, asleep, or hibernating. When the user turns their attention away, thinking that the system is inactive and secure, the attacker makes unauthorized use of the system.
Generally, whatever pattern of pixels a legitimate nexus-side program or functioning system can produce on the monitor, an attacking program on the host-side can imitate. However, in order to maintain the high assurance nature of the nexus, a user must be able to distinguish a legitimate nexus-side user interface graphic element from a fake one.
In view of the foregoing there is a need for a system that overcomes the drawbacks of the prior art.